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Speedup of Nost-IMP Interface 


Ts Introduction 


In order to mare the full nerformeance capabilities of the subnet 
aVallaole for interpreeess communication, tne hostis JMP nterface and 


+ 


the IMP's host interface shovla operate at Une highest speed obtainaple. 


First, tnis high throughput will minimize the Latency observed when 
RFNE'S, control messages, and NVE (network Virtual terminal) characters 
are Gueved behing gull sized messares. A full-size nessage curreéenoely 
ties up a L00 kp interface for almosy 100 sec, delaying shert messBeapec 
behand it by 2UC MSec. Speeding up the host inieriace to BUY Kalobeud 
wili shrink tale latency to 30 Msec. 


Secondly, this nigh-speed ogeration minimizes the time that the IMP 
buffer and the post core buffer ere locked goen during wessefc Uansier. 
(One being emptied, one being fillen), seing able to dispose of butters 
far faster Mews that many fewer of tnem will suífiĖice to carry tne 
communications tragfics: each buffer can of reused far more often. 


Third, high-speed cperation makes it possible to improve error controds | 
currenviy, a destination IMP returns a RENN after transinitting tne tarst 
packet ox a Hultinacket message to tne destination host. If an error 
Occurs auring the transmission of the (up to seven) other packets nto 
the destination host, the source host will nov ve informed of tne error: 
it hes already been given a positive message acKknovleugement in tne 
RFNM. Tne alternative, holding off tae FNM until all packeus nave ocen 
transmitted into the destination host, would add anotner 60 “Sec, tO the 
round trip Message ~= KERM time with the current 100 Kilobatuu interiace. 
A higher: speed interface will reduce this delayed ~ RFNM cost to a more 
acceptable value, making it practical to eliminate tnis source of 
undetected message transmission errors. 


Fourth, a high speed interface will permit greater nost communications 
bandwidth, (Currently limited to 100 kilobaud). ‘nis increase in 
bandwidth will be essential for communications between hosts at a 
"network-structureda" site, where different hosts on tne same IMP are 
Specialized to perform different parts of a computation. 


Clearly, any new or retrofitted host interfaces should pve very nign 


‘ 
» 


speed, and existing host interfaces should be adjusted to operate at 
their maximum speed, which is in excess of 300 kKilobaud. 


II. Experimental Results 


In support of the above predictions, the BBR TENEX staff performed an 
experiment in cocperation with the BBN IMP group to determine how fast 
the Systen A (BBaAeTENEX) and System D (BBKB) distant interfaces would 
operate. 


Results are as follows: 


The Hosteto-IMP connection is syncnronized by a tworwWay handshake wnicn 
hag an available burst bandwidth of 1 bits (2425 nsec + 3 nsec/fit,x<cable 
length>rt) For our cable Length, this results in a bandwidth of 310 
Kilooaud. 


The IMPeto=Host connection is synchronized by a four-Way handshake Which 
has an aVallable burst bandwidth of 1 bit/(1350 nsec + 6 nsec/ft.#<Ccable 
length>ét.) which results in a bandwidth of 290 kilopaua for our 
installation. 


Both System A and System B are now operating at this higher interface 
Speed. 


Since the propagation delay time through a distant host ariver=recelver 
pair amounts to 256 nsec, it is exvected that local hast interfaces — 
(<30ft) can be operated «zt sveeds Substantially faster than our 300 
Kilobaud. 


An addition to the above measurements of hardware speed, new results 
Were obtained in measurements of file transfer performance, iee, the CHU 
time and real time used per megabit of information transmitted over the 
network. 


This experiment involved the movement of one=megabit data files to and 
from an FTP User process in System BR communicating with the FTP Server 
Process in System A. The results are Summarized in tne following vaole: 


Operation p pyte Size Type Bandwidth User CPU seconds/negabit 
Get 8 ASCII L7RbAaUG Ve? 

Sena . § ASCII S0kbauad 7.9 

Get 22 Local Byte L3Kbaud 1.80 

Send 42 LocalByte 36kpaud 1.79 

Get 36 Image 7yxtaud 1.85 

Send 36 Image 8SkKbaud . 9b 
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The ponbit DanGwidth of around 60 xbeud is a great improvement from tn 
(typically) 2Skbaud measured before the speedup of the interface 
haraware. The CPU time use has also decreasea somewhat from that 


reported in RFC #557 ov Barry Wessler: this demonstrates continued 
improvement of systen efficiency between TENEX version 1.31 and TENEK 
VEEN: OM 1.32. 


In conclusion, the BAN-TENEK staff recommends that all host-InmF 
interfaces in the network ve Speeded up to the fastest operation 
obtainable. 


